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CHAPTER III 


- 


INTER-PROC EDURE COMMUNICATION 


3.1 INTRODUCTION 


Call, save, and return sequences are short sequences of instructions 
whose execution constitutes the standard way for one procedure segment to 
communicate with (i.e., transfer to, pass information to, and return from) 


another procedure segment.. 


The instructions in these sequences involve the management of the so- 
called "process stack, '' a special segment used by all procedures of a given 
process. Executing the standard call, save and return sequences also insures 
that all pure procedures are automatically recursive (and also sharable), a. 
deliberately planned by-product. Nonstandard methods of communication, 
whose use in special cases may improve efficiency, are by no means ruled 
out in Multics. They may be used by the advanced subsystem writer when 
appropriate. f The successful execution of any process depends upon flawless | 
management of the stack; hence (independent) translators, including assem- 
blers, that produce target code, are responsible for automatically generating 
call, save and return sequences. As a result the ordinary user is liberated 
from what might otherwise be an awesome task. In addition to user procedures, 
essentially all others, including those of the supervisor, the public library, and 
commands employ the same intercommunication sequences. A subsystem 
writer who is going to produce an independent translator must become thor- 
oughly familiar with details of this chapter, and of all pertinent MSPM refer-_ 
ences. The prime reference at this time is BD.7.02. Secondary references 

are BD.7.03 and BD.9. However, it would seem that any subsystem 


tA process may contain one or more groups of related procedure segments, 
so designed by a subsystem writer that intragroup communication is achieved 
without the standard call, save and return sequences. While executing within 
a group, short cuts can result in improved efficiency. At some point how- 
ever, such a group of segments must interface with system-designed pro- 
cedures, and here the method of communication must be standard. 


“ond 
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writer would need to become somewhat familiar with the process stack, its 


role and its management. 


This chapter begins with a discussion of the process stack and the call, 
save and normal return sequences for ordinary slave procedures. Argument — 
lists, their structure and creation are then treated. There is a brief summary 
of the storage structures for several types of arguments and a separate dis- 
dussion for function name arguments. Argument lists for calls to internal 
procedures are considered next. We postpone talk about generation of argu- 
ment lists for calls on procedures in outer protection rings (outward calls, 
BD.9). Chapter 4 will discuss protection rings. A few remarks concerning 


execute only procedures conclude this chapter ~ 


3.2 THE PROCESS STACK 


The key to understanding the effectiveness of call, save and return se- 
quences is to first understand the concept of the stack segment. There is a 
stack segment created for each process. f Each time one segment transfers 
or returns control to another segment, a frame of data consisting of key in- 
formation, such as index register contents, A and Q register contents, base 
register contents and other pointers, are either saved in the stack segment or 
retrieved or released from it. Moreover, while a procedure segment <b> is 
in execution, space for all its temporary storage is allocated in the stack seg- 
ment. When <b> returns to the program which called it, this temporary _ 
storage is automatically released by adjusting the stack pointer. The stack | 
is used as a pushdown store by carefully maintaining a current stack pointer, 
This pointer is kept in the sb<«sp base pair. The sb holds the effective 
pointer, i.e., to word zero of the stack segment, and the sp holds the relative 
position within the stack segment (current pointer) of word zero for the latest 


frame of data added to the stack. 


TStrictly speaking, as will be seen when we discuss BD.9, there is actually a 
stack segment created for every "ring of protection'' within the process. 
The notion of rings and multiple stacks and descriptor eee is purposely 
arta until eae 4. 


ay 


Figure 3-1 shows the layout of a typical stack frame. Each frame con- 
sists of a header (32 words) and a body. The header for the current frame on 
the stack is used to save the contents of registers and pointers, etc., which 
are meaningful to the currently executing procedure at the time it prepares to 
call on another procedure. The six words shown as not used should be con- : 
sidered as reserved for use of future system services. The body of the frame 
is of variable length and provides the temporary storage required by the cur- 
rently executing procedure. For PL/I procedures, for example, space for 
all variables having the automatic attribute is allocated in the body of a stack 


framef as soon as execution of the procedure commences. 


Normally the amount of space required for the body of the frame will be 
determined by the compiler or assembler. Therefore, at the time the frame 
is created, all the space required for the body can be allocated at one time. 
Allocation is in units of 8 words so that the immediately following frame 


header will begin at an internal address that's congruent to zero (mod 8). 


Figure 3-2 suggests how the <stack> grows frame by frameas execution 


moves from <alpha>to <beta>, then to <gamma>. 


Figure 3-3 gives a closer look at the frame developed for and during exe- 
cution in <beta>. We find it convenient to think of the frame header as con- 
sisting of seven items, so marked inthe figure. Each header item is marked 


in its upper right corner to denote which sequence, i.e., call or save, is re- 


sponsible for placing the item inthe header. (The item numbers used in Figure 


3-3 are used repeatedly in subsequent discussions. ) 


3.3 THE CALL SEQUENCE 


Whenever we wish to transfer from one procedure to the next we would 
issue what amounts to a standard marco call. For example, the call macro 


in eplbsa has the form: 
call entrypoint (arglist) 


TAlso, the "specifiers and dope" for some types of based controlled variables 
are kept in the stack frame. See BP.4.00 for more details. 


fExceptions arise when the stack frame must be extended during execution of 
the procedure, as discussed in Section 3-4. 
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<stack> 


other stack frames 


sp+0 


save base register contents. | = : 
here (before transferring 
to another procedure) 


8 
save index register, A, Q,E, andTR 32-word 
register contents here (before header 
transferring to another procedure) 
| 
16 backward pointer "a - | 
(to preceding frame) ; @ 
18 next sp forward pointer a fe : | eg 
(to next frame) 
20 point of return in calling 
| | procedure 
22 | used only by execute-only procedures stack 
| frame . 
24 es 
not used 
——— . 2 
26 save pointer to argument list | 2 it Sie, GeO 
here before transferring | | | 
28 ie - > we es 
not used 
ae 
32 
temporary 
storage 
required for 
executing 
the procedure 
n(>32) 


Figure 3-1, Layout of a Typical Stack Frame. 
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<stack> 


stack frame for <alpha> 


(a) <alpha> is being executed 


stack frame for <alpha> 


i 
ae 
pal 


header 
stack frame for <beta> 


body 


(b) <beta> is being executed 
after a call from <alpha> 


stack frame for <alpha> 


stack frame for <beta> 


stack frame for <gamma> 


(c) <gamma> is being executed 
after a call from <beta> 


Figure 3-2. Showing Development of <stack> During a Chain of Calls. 


< stack > 


save 

contents of 8 abr's 
at time of transfer 
to <gamma> 


save 

contents of 8 index 
registers, A, Q, E, and TR 
registers at time of 

transfer to <gamma> 

See Fig. 3-4 for details 


for procedure which 
called on <beta> 


Stack is called from <alpha> and (filled in when this 


is in preparation for a call on frame is created) 
<gamma> . Mick 
frame 
created 
: for 
<beta> 


not used 
(do not use) 


pointer to argument list 
(actual args) for call on <beta> 


not used 
(do not use) 


temporary 
storage | 
while 
executing in 
<beta> 


Figure 3-3. Appearance of Stack Frame When Executing in <beta> 
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Here entryp oint is the entry point of the procedure being called (any type 
of address may be used for entrypoint), and arglist is the location of the argu- 
ment list. (Any type of address may be used for arglist, but we shall assume 


throughout this chapter that argument lists are always kept in the stack. ) 


For example, if eplbsa encounters: 
call< gamma> | entry2] (sp| arglist) 


entrypoint | arglist 


| in processing the code for < beta>, then the expanded sequence will be: 


save contents of the 8 abr's in 
-spt0 thru spt+7. Item 1. 


save contents of the 8 index registers, 
A, Q, E and TR registers in spt+8 thru 
sptl15. Item 2. See Figure 3-4. 


sreg sp|8 


eapap sp|arglist | place the pointer to the argument list 
, | inab<apfor use by <gamma>. The 
| argument list is Kept in temporary 


storage. 


stcd —sp|20 save the point of returnto <beta> i.e., 


4 
(ic)+2, and (pbr), and (indicators) in 
spt+20 and sp+21. Item 5. 

5 tra < gamma>|[ entry2 | | transfer to called procedure (via the 


mechanism described in Fig. 2-13). 


The first, second and fourth instructions store items l, 2, and 5 in the 
frame header. { If we ever return to <beta> and at some later time issue a 
new call, possibly to some other procedure, new values for items 1, 2, and 


5 would be stored in this header. 


Item 5 has the format of an its pair 


| | (Gp eg a 


Ls ee 


fIn the more elaborate call sequence for execute-only procedures there are 
also instructions to store Item 6. See BD.7.03 for such details. 
3-7 


<stack> 


index registers 


, as 
a 
=e 
sf 
<., ee: 
a 
| 
4 


A-register 


Q-register 


E (exponent register) 


9 bits 
TR (timer register) — 


24 bits 


| Figure 3-4. Saving Index Registers, A, Q, E, and TR 
| Registers upon Execution of: sreg sp | 8. 
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The tra instruction of the call sequence will be assembled as 
tra Ip|k, * 


The symbol "k'' represents an offset within <beta.link>. The ft2 pair at 


this location is converted by the linker (as explained in Section 2.9) to the its 


gamma. link# 


The pair of instructions found at gamma. link#| dist, you will recall, is 


- pair: 


for the purpose of (1) loading gamma. link# into the lb base register (and 
normally a zero into lp) and (2) transferring (via another its pair) to — 


gamma#|entry2. If you have forgotten how this mechanism works, you should 


review the diagrams given in Figure 2-13. 


3.4 THE SAVE SEQUENCE 


The purpose of the save sequence is to (1) generate a new stack frame of 
32 or more words for the just-called procedure, and (2) supply values for 


items 3, 4, and 7 in the header of the newly formed frame. 


Before we explain the details of the save sequence we make the following 
general observation. If we continue following the example of <beta> calling 
on <gamma> (as we shall here), the items 3, 4 and 7 about to be established 
will be those of the <gamma> frame. To see how the corresponding items 
would have been established in the <beta> frame given in Figure 3-3 we would 
have to shift the reference point of our example to that of <alpha> calling on | 
| < beta>. We prefer instead to continue the ''walk" through one complete call, 


save and return cycle that starts with call. 


The save sequence for <gamma> is actually stored in two parts. Part 1 


consists of the eaplp, aos, tra, arg cuadruplet? and the link, which are kept 


in < gamma. link>:T 


dist: eaplp -*,1C. 
aos 2,1ic 
tra link2-, *ic* 


arg — 0 
{This is the way it's viewed in the MSPM (BD. 7. 02) i 


tEffective 2/12/68 the eaplp, tra pair is replaced by the quadruplet shown here, which includes 
a usage counter to keep track of the number of times an entry has been used. The aos instruc- 
tion adds one to the location immediately following the tra instruction, (Drafts 2 and 3 of 
Chapter 2 do not show this Ce peecentee: a 
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link2: 


The effect is to establish the lb<lp pair for pointing to < gamma. link>, and | 
transferring to <gamma>. Part 2 is kept in <gamma> proper, beginning at 
entry2. This part has the job of creating the new stack frame of size tnew _ 
and storing item 7 (the argument list pointer) into it. A new stack frame is 


said to be created when 
(a) the new frame contains a pacewasa pointer ee (3). 
(b) the new frame contains a forward somber é6 the next fe auue (item 4). 
| (c) the sb<sp pair is reset to point to the beginning of the new frame. 


A crucial Multics pede een is ; that Aaeine the course of executing instruc- 
tions to create a new frame, there must never be an instant when the beginning 
of the next frame (i1.e., the frame beyond the last fully created one) is | 
undecidable. The reason is simple: The Multics supervisor uses the same 
stack to store the stateword of this process (i.e. , register contents, etc.) in 
the event of a hardware system interrupt. If such an interrupt occurs during 
creation of a new stack frame there must be a completely safe way to identify 
the beginning of the next frame for use in handling the interrupt. The handler 
always locates safe-to-use storage ata pone in the stack beginning at 32 words 


beyond the Peginning of this frame. 


The save sequence instructions af Part 2, shown immediately below, are 


especially designed to meet this objective. 


1. | entry2: eapbp- sp|18,* Save item 4 of the current frame 

4 temporarily in bb« bp. That is to say, 
let bp temporarily become the stack 
pointer for the new frame. 


Store current sp value, i.e., SP 5 
as item 3 of the new frame 


Zi . stpsp bp |16 


Create item 4 for the new frame in 
bb<bp by adding tnew to what is 
already in bb<bp (item 4 is a 
pointer to the frame following the 
one currently being created). 


3. _- eapbp-~—s bp |tnew 


Store item 4 for new frame in 
position 18 of new frame. (It's 
stored in spyttnew+18-tnew or 


Spy+18). 


4, stpbp bp| 18-tnew 


Form new stack pointer, i.e., sp 
in sb+sp, by setting the sp part — 

of sb« sp to point to the beginning © 
of the frame for gamma (i.e., the 
bp part of bb<bp minus the length 
of the new frame). 


oe eabsp bp| -tnew 


Save item 7. I.e., save the argu- 
ment list pointer left in ab<ap 
by <beta>. 


6. stpap sp| 26 


| 
| 
| 
| 
| 
| 
| 
| 


Note that at any given instant the frame pointed at by the sb<bp pair is 


the last fully created frame. Upon completion of the fifth instruction in the 
sequence (eabsp bp| -tnew) the new frame has been fully created. Interrupts 
occurring any time before or after this instant are treated as shown in Fig- 


ure 3-5, 


The particular instructions used in this sequence depends on the size, 
tnew, of the frame being created. The value of tnew! can ordinarily be 


determined by the assembler or compiler. 


tThe maximum value that can be used for tnew in the type 1 instructions of the 
save sequence is 2°*. If a frame having a size in excess of 2!4 words is to 
be allocated, two additional instructions may be generated at the end of the 
sequence: | : 7 


eabbp _ bp| excess | sd Sucens 26 copy of item 4 and 
stpbp  sp|18 | store as revised value for item 4. 


| 
This works if excess is itself <2l4. A somewhat slower-to-execute sequence 
would be needed in building frames whose length ranges up to 2'° words. One 
such sequence might be: 


adbbp excess, du | type O instruction: add excess 
| to current contents of bp. The 
peu, or direct upper modifier, 
indicates the value of excess is 
| in the address field of this 
| instruction. 


| | 
stpbp sp| 18 | store as revised value for item 4. 
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<stack> 


32-word 
header B-frame 
eed 
header | f 
y~frame 
interrupt handler | | , 
will use space —_ tnew 


beginning here for 
storing stateword, 
etc. 


| 


Case (a) If interrupt occurs before 5th 
instruction of save sequence 


-_ 
a. 
Q 
3 


a | 32-word 
a ee _ . _ | item 4 header 


y~frame 


tnew 


header 
or next frame 


b 


Case (b) If interrupt occurs after execution 
of 5th instruction of the save sequence 


interrupt handler 
will use space 
beginning here for 
storing stateword, 
etc. 


Figure 3-5. Handling Interrupts Before and After Btn 


Instruction of the Save Sequence 
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In short, upon completion of the save sequence in <gamma> we've set the 
sb<sp to point to the beginning of the new frame of tnew words. Item 3 (sptl6) 


has been set to point backward to the beginning of the preceding frame for 


_<beta>. Item 4 points forward to the beginning of the next frame, and item 7 


holds a copy of the pointer to the argument list of the call to <gamma>. If, 
during execution in <gamma>, additional amounts of temporary stack storage 
are required, more space may be allocated to the frame simply by altering 
item 4.7 | 
The instructions: 
eapbp_—_sp| 18, * 


get current value in item 4. 


increment by extra (which should 


| 
eabbp _— bp| extra | 
| be a number that's congruent to 
| 
| 
| 
| 


a 0 (mod 8) and <2!4. 
stpbp sp|18 store new value of item 4. 


would do the job. 


Also, by way of summary, the following is the condition of the abr's 


upon completion of the save sequence in <gamma>. 


Pp b 


a oe 


temporarily holds a 
pointer to the first 
word in <stack> beyond 
the <gamma> frame 


3.5 RETURN SEQUENCES 


There are two types of return sequences which can be executed, the 


normal or standard return to the point of call and an abnormal return, i.e., 


a return to a program point within an arbitrary procedure which point has 


been supplied as an argument. We shall discuss only the normal return here. 


#T 0 give you some idea where stack extension might be used, you should note 
that in the original EPL implementation, temporary arrays that are adjustable 
are allocated space (when their space requirements become known) as exten- 
sion of the current stack frame. 
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A subsystems writer should ordinarily implement or employ abnormal returns ! 


only where necessary, i.e., only where the extra overhead is justified. 


3.6 THE NORMAL RETURN SEQUENCE 


If you've followed what is required in the call and save sequence, the 
normal return sequence is quite simple to understand. All that's needed for 


<gamma> to return to <beta> is to 
(1) reload the base registers and index registers, etc., (all but the 
TR register) whose values were saved in the Setar frame during 


<beta>'s call on <gamma> and 


(2) restore the ic and pbr (and indicators) registers to the values tucked 
- away as item 5 in <beta>'s frame. | 


Only three GE 645 instructions are actually required. The eplbsa macro 
call, 


return 
expands to: 


lIdb = sp| 16, * reload 8 base registers 


A, Q, and E registers 


| | | : 
lreg sp|8 | reload 8 index registers, 


rtcd sp| 20 | "restore control word double" 


The first of these instructions loads the 8 base registers from the location 
pointed to by the contents of sp| 16, which is item 3 of the <gamma> frame. 
Item 3 is the backward pointer to the top of the <beta>frame. The net effect 
is to reload the base registers stored in the <beta> frame. As a consequence, 
the sb<sp pair will now point to the beginning of the < beta> frame instead of 


the <gamma> frame. 


The second instruction in the return sequence will reload all 8 index 


registers and the A, Q, and E registers using the direct address: 
| sp|8 


since sb<sp now holds the desired pointer. Finally, the third instruction 


TThese are handled by calls to the unwinder, a supervisory routine described 
in BD. 9.05 and discussed fully in Chapter 5. | 
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rtced sp|20 


recovers all other machine conditions, i.e. “: (ic)+2, (pbr) and (indicators) 


which were safe-stored as item 5 in the <beta> frame at the time <beta> 
called <gamma>. The effect of the rtcd instruction, a very fancy transfer 
instruction, is to resume execution at a place two words beyond the stcd 


instruction in the calling sequence to <gamma>. 


3.7 BASIC STORAGE STRUCTURE FOR AN ARGUMENT LIST 


All compilers and assemblers Operating in the Multics environment must 
produce lists of calling arguments that fall into certain standard patterns. 
Every Operating system requires such standard patterns. In the familiar 
batch operating system on conventional computers, the argument list is © 
usually supplied as a set of pointers or values immediately following the 
transfer and save (ic) instructions (e.g., TSX in the IBM 7094). The Multics 
argument list, however, may be stored in an arbitrary location, but is gen- 
erally kept in the stack in order to keep the procedure pure and to guarantee 


that it is recursive. T Moreover, the list consists only of pointers. No actual 


| values are stored in the list. 


Figure 3-6 shows the ''basic'' storage structure used for an argument 


list. * It consists of a two-word header, followed by a body composed of n 


its pair pointers. The length of the body, 2 Xn words, is given in the header 


whose address is sp| arglist. 


Each its pair can point independently, either directly or indirectly to a 
corresponding argument. The its pair normally has a zero modifier, i.e., 
direct, when the argument is local to the calling procedure. Indirect modi- | 
fiers, *, are useful when the argument is externally defined as will be ex- 


plained in a later paragraph. 


TAn argument list must be generated and stored in the stack if at least one 
of the datum values it points to must be kept in the stack. This means that 
several copies of the argument list, each pointing to different ''generations"' 
of arguments, can be stacked at the same time. By a datum value we mean 
for example, a variable, label or procedure entry point. 


#This form must be embellished in one of two ways to achieve "special effects, '' 
One of the embellished forms is discussed in Section 3.11, the other in Chap- 
ter 4. _ | , 


3-15 


- Sstack> 


along ae 


header 


body is a 

list of n 
pointers to the 
n arguments 
in the call 


This structure is for a call to an n-argument procedure segment, The m, 


are modifiers which are normally 0 but which may be * (indirect). 


Figure 3-6, Basic Storage Structure of an Argument List. 


@ | 3.8 PUTTING ITS PAIR POINTERS INTO AN ARGUMENT LIST 


The creation of its pairs for an argument list and the insertion of them 
in the list requires one of several coding technique, depending on the kind of 


argument in the call. Three kinds are recognized here: 
(a) argument is locally defined within the calling procedure 


(b) argument is a parameter of the procedure, i.e., passed 
along as an argument by a procedure which called the 
currently executing procedure | 


(c) argument is an external symbol 


The different coding techniques are alluded to in BD. 7. 02 under Notes and 
Comments, Inthe remainder of this section we give a small amount of elab- 
oration. Feel free to skip over these details during the first reading. Prob- 
ably even more detail is needed for subsystem writers who will be writing © 


compilers or assemblers. 


We shall sketch how each of the three kinds of argument pointers might 

be formed by basing our examples on the following hypothetical situation. We 
@ imagine source code which shows <a> calling on <b> which in turn calls on <c>. 

We then focus on the job of the compiler which must construct the code to gen- 
erate an argument list for a call within <b> on <c>. We further suppose in 
all instances that this list is to be located at sp|arglistb. Let the _ argument 
in the call on <c> be given the name xb. | 

(a) xb is locally defined within <b> and hence its value resides in the 
stack frame associated with <b>, say at some offset xxb from word zero of © 


the frame. This offset is computable by the compiler. Suitable code to cre- 


ate and store the desired its pair pointer in this case would be: 
eapbp sp|xxb form address of argument | 
stpbp sp| arglistb+2*i store as ae its pair in arglistb 


(b) xb is a parameter, say the Aes parameter of <b>. In calling on <b> 
we know that the procedure <a> has provided an argument list with an its pair 
pointer to this ata argument. Suitable code to form the i its pair pointer for 
: xb would be: | | 
i © at \ Idaq ap|2*j 

f: a stag sp| arglistb+2*i 
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The ldaq instruction lifts the its pair ''bodily'’' out of the argument list supplied ss @ 


by <a> and puts it into the argument list being constructed at splarglistb. 
Notice that it would be a mistake to use code such as: 
eapbp ap |2*j 
stpbp sp | arglistb+2*i 


because this instruction pair would store a pointer to the pointer in <a>'s 


arglist, i.e., the its pair: 


cee a 
arglistat2*}j ‘of o- 


where (ab) means the contents of the ab base register. 


pointer to the 
arglist pointer 


(c) the i argument is an external symbol. In this case, the its pair 


which must be created and put in the argument list includes a segment number 
and an external symbol, values for which are not known to the compiler at 


the time it's generating the code that creates this argument list. 


For example, suppose the fh argument is to be <data>|[x]. Source @ 


code like: | 
eapbp <data> | [ x] 
- stpbp sp|arglistbt+2*i 


would, when executed, certainly create the desired its pair, but in so doing 
would force an ft2 fault to the Linker which must determine data# and x. This 


is because the generated code will be of the form: 
eapbp lIp|k, * 
stpbp sp| arglistb+2*i 


The trouble with this approach is it forces linking at too early a stage. 
After all, we don't really know if the called program <c> will ever use this 
argument. So, why link to it during the process of calling <c>? If <c> never 


uses this argument the early linking could be a costly strategy. 


A way to postpone this early linking, is to create an indirect its pair | 


pointer for the argument list. 


Coding which could be generated to do the job night look like: 


eapbp —_Ip|k Pu we | form address of ie ft2 pair 
| . for <data>| [ x] in base pair 


_stpbp 7 Sp| arglistb+2*i 


| store the sadraes (i.e. NB] lp+k) 
| as an its pair . 
lda | 16, dl | Te an indirect code, which is 
| decimal 16, into lower part of 
| accumulator. dl means ''direct 
| lower"! 7 | 
orsa sp| arglistb+2*it] | or or the accumulator to storage 


to form an indirect modifier in © 
| the second word of the its pair 


An its pointer will then be cone eredver wie fora 


sp |arglistb+2*i 


where (lb) and (lp) represent the contents of the lb and lp base registers at 
the time the eapbp instruction is executed. For a more complete a SueeTOE 
on how to handle such arguments: see BB. 2.02. 7 


3.9. STORAGE STRUCTURES FOR DIFFERENT TYPES OF DATA 
Thus far we have been discussing lists of pointers to the aeganente of a 
procedure, but we haven't been paying attention to what the arguments them- 
selves look like. Some types of arguments, e.g., integer and real variables 
are sufficiently simple that their data values are pointed to directly by the 
pointers in the argument list. Other data types are sufficiently complex in 
structure that the argument pointers don't point to data values but, alas, to 
- pointers which are part of the storage structure of the individual arguments. 
The subsystem writer must, of course, keep this in mind in instances where 
code is being constructed to fetch or store data values via argument list 


pointers. 


At least some of the procedures of every subsystem must interface with | 
Multics system modules. Arguments passed to orfrom a subsystem procedure 
and a Multics system module are restricted intype to a subset of PL/Idatatypes. t 
fit may surprise you to learn that, although most of the Multics system is 


| written in PL/I, the data types used are a restricted subset within that 
} = language. For motivation and full discussion of this point, see BB.2. 
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Only the following types of arguments may be passed: | | - & ® 


(a) All scalars: 


oo integer — 
arithmetic < real 
| complex 
| abet Ss. pat 
5 _) character 
labels (including procedure entry points) 
pointers 


(b) Any one-dimensional array of the above. 


Standardized storage representations (structures) have been established for 
each of these types and are given in section BB.2.02 of the MSPM. We provide 
here a convenient summary of these storage structures. These are the items | 
in Table 3-1. In each case, the graphic form denotes the item of 
the argument pointed to by the pointer in the argument list. Shaded boxes 
denote parts of the argument containing actual data values. Unshaded boxes 


denote pointers or ''dope."' oer oa : a _ 


_ Shown in Table 3-2 are the storage structure conventions established for 
the remaining data types within PL/I. More details on these latter items can 
be found in the MSPM documents which relate more eae to PL/I (i.e., 
BD.1, B0056, BP.2.01, and BP. 2.02). | 


Table 3-2 items should also be of interest to the Babess ers writer, but 
for somewhat different reasons. Thus a subsystem writer who is developing a 
new language processor, e.g., MAD or ALGOL, may benefit by seeing the 
way n(2>2)—dimensional arrays are structured in the Multics PL/I. While 
these are perhaps not the best or only methods for representing such data 


types, two things are worth considering seriously: 
(1) These structures are tested and have proven practicable. 


(2) Multics will eventually provide an extensive library of subroutines 
written in PL/I. A subsystem writer who chooses PL/I storage | 
structures can have the automatic by-product of being able to have 
his subsystem interface easily with (i.e., call directly on) a grow- 
ing library supported by the Multics staff and the PL/I oe 
enoues said. 


oe 
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TABLE 3-1 


Types of Arguments and their Storage Structures — System-Wide Standards 


Argument Type Storage Structure 


Non-string Scalars 7 » 

a ote ©)- Mii —— 
Double-word integer <i ORE 
: AUXIN odd 


Single-word floating - point | (P) AAAAAAAN 


Single-word integer 


Double-word floating-point he NANRRRARNT os even 
| NANNARRAR | 
Single-word floating-point al (P) Ry even (real er 
Complex | VAAANAN _ (imaginary part) 


Double-word floating-point 
Complex 


AN 
IRA 
INNRRRRARN 
oe AAA 
String Scalars | 
Non-varying bit strings er 


words as 
required 


Non-varying character strings 


Same as 9, 11] above Sebepe add another 
its pair to the specifier to pom, to free 
storage. See BB.2.02 | 


ANSE a EA 
Re] Sic Ao 

eel — dt link type 
type — type 


Varying bit peer oe 


Varying character eines 


Program Gonteel Data 


_ 


Absolute pointer 


Relative pointer 


i Numbering here is same as symbol type number (BD. 1, p. 10) used as a code 
in the segment symbol table. 


TABLE 3-1 (continued) 


Types of Arguments and their Storage Structures — System-Wide Standards 


Type : | 
No. . Argument Type Ea Storage Structure 4, 
: 


Label program point in 
<x. link> 
‘Same storage . 
stack pointer # 
structure 
not now used 
Entry 


One-Dimensional Arrays 
of scalars, types 1-8, one 
and 13-16 contig- 
uous 
block 
of 


storage 


| See BB.2.02 for | 7 @ 
: more details which ~ | 
will reveal its full | 
| | generality....idis 
a nine-bit code that 
| | | describes the type of 
the structure and size 
| of the elementary data 
| item 
| 


specifier 


25,27] of scalars (non varying 


strings), types 9 and 11 oe 


contig= 
uous 
block 
of 
storage 


7 words 
See BB. 2.02 for 
more details which 
reveal its full generality... 


26,28] of scalars (varying strings), 
types 10 and 12 See details BB. 2.02 


to the stack frame that defines the generation of temporary storage appropriate 


to the program point. 


TABLE 3-2 


Types of Arguments and their Storage Structures — PL/I Standards Only. 


San Argument Type , Storage Structure | 


Higher-dimensional Arrays | 


specifier 


one. 
contig- 
uous 
block of 
storage 


17-24] of scalars of types 1-8 


3m + 3 words, 
where m = number 
of dimensions in the 
array (See BP. 2.02). 


. specifier 
of non-varying string 
one 
bit strings contig- 
character strings uous 
| block of 
storage 


3m + 4 words, 
where m = number 
of dimensions in the 
array (See BP. 2.02). 


of varying strings 

bit strings 

character strings 
(same as 25 and 27, except 
we add one more its pair 

to the specifier which points | 
to free storage) | 


scalars | | 


1 See footnote to Table 3-1 
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TABLE 3-2 (Continued) 


Types of Arguments and their Storage Structures — PL/I Standards Only. 


Type 
No 


Argument Type Storage Structure 
Structures 


one 
contig- 
uous 
block of 
storage 


3+ n words, 
where n = number 
of substructures 
See details, 
BP. 2. 02. 


dopes for up to 
n substructures 
that may have dope 


Arrays of Structures _ - See BP. 2.02, 


3.10 FUNCTION NAME ARGUMENTS, ORDINARY CASE 


A procedure <p> may call on another pnocedare <r>, passing to it an . 
argument that is a procedure entry. Suppose the argument passed to 


<r> is the procedure entry <q>| [entry3], in a call equivalent to 


call <r>|{ entry] (arglist1). 


In this case the argument list contains a pointer to the entry datum which 


has a pointer to <q>|[entry3] . Some time later, while executing in <r>, we 
can have a call on <q>, by referring to a parameter, say t, that corresponds 


to <q>. Such a call might have the appearance: 


call t (arglist2) 


where t is declared to be the dummy procedure name, and the arguments, 


x, y, and z are recognized as external symbols for (say floating point) vari- 
ables located in the segment <data>. A corresponding sketch is shown in 


Figure 3-7 using eo terminology. 


The argument list generated in the sai to <r> will have the appearance: 


arglistl 


The argument itself we suppose is located at sp|arg. It has the format: 
entry datum 


sp|arg+0 


normally zero 
(used only for 
internal functions) 


unspecified error 
check information 


p: procedure; ae 3 q: procedure (a,b,c); 


r: procedure(t); 


dcl(data$x ,data$y, 
data$z) float; 


call t(data$x,data$y, 
— data$z); 


: Figure 3-7, Calling an External Procedure Whose Name (q) 


has been Passed as an Argument. 


ei procedure: | | | _ | > procedure(t); 


dcl w fixed binary (17) dcl(data$x ,data$y, 
automatic data$z) float; 


call r(q); 


call t(data$x ,data$y, 
data$z); ~~ 


q: procedure(a,b,c); 


| Figure 3-8, Calling an Internal Procedure Whose Name (q) 


has been Passed as an Argument, 


The first its pair points to an offset within <q. link> at which we can 


expect to find the quadruplet 


entrypair: eaplp  -*,ic 
aos Zee 
tra link-*, ic* 
arg 0 


whose execution basically results in the transfer to <q>|[ entry3]. Ordinarily 
the second pair of words in the entry datum is zero, In certain cases, how- 
ever, as explained below, it will be used for holding a stack pointer value. The 


third pair, is to be used for as yet unspecified error checking information. 


To generate the call on the dummy t while executing in <r>, the last 


instruction in the call sequence might be preceded by the instruction: 
-eapbp ap|2,* — 


to put the address of the function name argument in bbebp. The standard call 


sequence would follow, ending with the instruction: 
tra bp| 0 


which would cause the transfer to the address found in the first its pair of | 
the function name argument, i.e., ultimately to the desired entry point in 


<q>. 
The argument list that goes with this call on <q> would appear as: _ 


arglist2 +0 


3.11 FUNCTION NAME ARGUMENTS, SPECIAL CASE _ | 6 
| 


Suppose again the procedure <p> calls on < r>, passing to it as an argu- 
ment an entry point ing. But this time, suppose q is a procedure that's in- 
ternally defined within <p>. Figure 3-8 illustrates this case using PL/I 
terminology. We will imagine that the entry point is located at qtentry3 
within <p>. Because q is an internal procedure, it may, whenever it is 
executed, require data values which have been allocated temporary storage 
in a stack frame created earlier by the containing procedure < p>. Somehow 
q will have to know how to reach this stack frame. This section explains the 
Multics conventions which are designed to aid subsystems writers in solving 
communications problems of this ty pe. Such problems, of course, will occur 
in subsystems which permit the embedding and or the nesting of internal pro- 


cedures or blocks within procedure segments. 


To continue with our example, suppose then, <p> calls <r> with a call 


equivalent to 


call < r>|| entry 1] faveiiel) 


The argument list at arglistl looks just like the one we showed in the preceding 


discussion. However, the argument itself must now include a stack pointer 


value for reasons we shall be developing in the next paragraphs. Thus, our 


argument at sp|arg would now appear as: 7 | 


entry datum 


gt 4D 


sp arg+0 


Each call sequence that sends control from <p> to <r> must be immedi- 


ately preceded by code that creates an argument in the above form. 


The first its pair points to the entry instructions within <p. link> whose 
execution would result in a transfer to <p>|qtentry3. (sb) and (sp) refer to 
values of the sb<-sp base pair extant immediately prior to the call. Code to 


generate the first two of these its pair could be: 


eapbp lp | entrypair _. | form the address p. link# | entrypair 


stpbp sp|arg | store as the first its pair in 


| the function name argument. 
| : | | 
stpsp sp| argt2 | | store stack pointer value as the 
| | second its pair. 


Proceeding further with our example of Figure 3-8, we now suppose 
that, while executing in <r> at some point, we wish to execute a call on q 


via reference to the corresponding parameter t, e.g., 
call t (arglist2) 


Here again, t isthe dummy procedure name. The arguments x, y and z 


happen to be externally defined within <data>. 


- Once the call sequence in <r>to p# |qtentry3 has been completed it 
must be possible for the computation of q(x, y, z) to proceed successfully. 
But suppose that while executing in q it becomes necessary to refer to a pre- 
viously stacked data value such as w that was assigned during prior execution 
in<p>. Remember that the compiler does not and cannot furnish addresses 
that are relative to the beginning of the stack segment. It only furnishes ad- 
dresses relative to the beginning of a stack frame. Therefore, q must know 
the stack frame pointer that was in use at the time <p> called <r>. Note 
this is the pointer that would be made a part of the function name argument 
to be "passed'' to <r>. Obviously < r> itself has no need for this stack pointer, 
but notice that when <r> calls on q, <r> can pass this pointer back to q as an 
argument. Ina sense, the stack pointer must make a "roundtrip" from <p> 


to <r> and back to <p>. We now see why a function name argument (entry 


datum) that refers to an internal procedure is designed to include the current 


stack pointer value. 


In just a moment we will examine the structural form of the argument 


list that must be used in calling onq. Before doing so, we might digress 
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here to ask several questions: What sort of call sequence should be used in | : & 
calling an internal procedure? Should the standard call sequence be used? In 

any case, how should execution proceed in an internal procedure like q once 

it is called? Should there be a save sequence executed to create a separate 

stack frame for execution of q? Anyone writing a compiler for a language 

that has an ALGOL-like block structure, e.g., one which permits the nesting 

of internal procedures and/or PL/I-like begin blocks, must provide his own 


answers to these questions. 


Mechanisms have been developed by the EPL compiler writers for dealing 
with these problems. They are well documented in MSPM. Other compiler 


writers may choose to adopt these techniques. If so, they will find the notes 


in BN. 5.01 very helpful. They should keep in mind, however, that the imple- 
mentation described there is regarded by its developers as somewhat clumsy | 


and subject to improvement. _ 


The notes in BN. 5.01 suggest one mechanism for handling the general 
problem which arises when the called procedure or block may be nested at any 
depth within a containing external procedure. The bookkeeping becomes | | -_ 
more complicated, because successful execution of the called procedure may @ 
require knowledge of a (different) stack pointer for each of the ''containing" | | 
procedures or blocks. That is to say, a mechanism is developed for knowing, | 
when executing within a procedure or block that is nested at level i, where to 
find stacked data that was generated by containing procedures or blocks at 
various ''shallower'' levels k < i. Inthe EPL implementation, begin blocks 
are treated indistinguishably from internal procedures. To enter a block one 
issues a standard call sequence, as if it were a procedure. Once called, the © 
internal procedure executes the standard save sequence to create its own | 
stack frame. Among other things that can be stored in this frame is the 
(set of) stack pointer(s) to the frame(s) for any outer level procedures that the 


called procedure needs to refer to. This set of stack pointers is referred to 


as the "display. ‘ 


The cost associated with a call to a nested procedure or block in the cur- 


rent EPL mechanism unfortunately increases with increase in the depth of 
nesting. This objection is serious enough that work is progressing on im- | 
proved techniques which would have the virtue that calling costs are indepen- a @ 
dent of nesting depth. | | | : 
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We are now ready to discuss the structure of the argument list that is 
used for calling on an internal procedure. This Multics ''standard"' takes 
the form of a simple embellishment to the structure of an ordinary argument 


list. The extended form is shown in Figure 3-9. 
In our particular example we see that the PL/I statement 
call t (data $x, data $y, data $z); 
| corresponds at assembly level to 
call t(arglist2) 


with an associated argument list which would look like: 


arglist2+0 


copied here 


In point of fact, eplbsa does not automatically generate the code to 
construct the argument list in the expansion of the call macro, although an 
assembler with a more advanced macro capability could be expected to do so. 
This means that any compiler designed to generate eplbsa code as output 
must bear the full responsibility for generating code to form the argument 
list before generating the call macro. 

If we were to imagine the use of a more advanced assembler, then 
conceivably, a source statement like 


call t(< data>| [x], <data>| [yl], <data> | [z]) 


indicates an extra 
pair in the follow wine 
list | 


n argument 
pointers 


so sieraeeeeeaeeiemanemaceemmarneenel 
re en eR 
rc a 


stack value for last generation 
of storage associated with the 
procedure being called 


This structure is used when calling on an n-argument internal procedure whose 


name was previously passed as an argument. 


Figure 3-9. Structure for an Argument List. 


could be recognized. The assembler would then generate: 
(1) the code to form the complete argument list 
(2) the call sequence 


such an assembler would have to automatically recognize that tis a 
dummy that representing an internal procedure in order that it (the assembler) 
could know to generate code to form the n + lst its pair of the argument list. , 
A sophisticated assembler could recognize that t is an internal procedure as 


follows: 

Since t is a parameter, the assembler must generate code which, when 
executed, determines if the entry point that corresponds tot is internal or 
external. If external there is of course no need to add the n + Ist pointer. 

The distinction can be achieved by inspecting the second its pair in the entry 
datum. If it is zero, the entry must be external because otherwise this pair 
would hold a stack pointer. Code like the following would, if generated, per- 
form this discrimination during execution, and add the its pair as needed, etc. 


eapbp | ap | 2*i, * | | establish pointer to function name 
@ | : | | | - | arg, assuming it is the ith argument. 
ldaq bp|2 pick up (sb), (sp) from second its 
pair of this arg. | 


tze _ skip bypass! 


store stack pointer value as n+ lst | 
argument in call onq 7 7 


staq —sp|arglist2+2*n+2 


adjust word zero of 
argument list 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
skip: | 
| 
| 
| 
| 


TIn the GE 645, execution of the ldaq instruction causes the zero indicator to 
© | be turned on when the loaded double word is zero. 7 
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Once inside the called internal procedure, any reference to a local 
(automatic) variable in the contai ning procedure <p> must be accomplished 
via the stack pointer argument, In our particular example, a reference to | 


the variable w by the procedure q might be coded something like: 
eapbp ap| 8, * 


lda bp|w 


3.12 COMMUNICATION TO AND FROM EXECUTE-ONLY PROCEDURES 


Communication to or from execute-only (E@) procedures justifies separate 
discussion. The communication process for such procedures is necessarily 
more complex. Special code must automatically be generated within E@ pro- 
cedures and in their linkage segments which will control access to them and 
at the same time allow flexibility in their use and still permit them to be pure, 
and hence sharable. Thus: Although any call on an EG procedure must begin 


execution at word zero, so that the call can be examined for some sort of 


validity, we still want to allow such procedures to effectively have multiple 


entries. Moreover, although any return to an EQ calling procedure must 
actually resume execution at word zero, again, for validation purposes, we 
still want to permit the writer of the E@ procedure to effectively imply or 


specify any program point for a normal or alternate return. 


You should have little difficulty appreciating the communication objectives 
and problems, which are clearly set forth in BD. 7.03. The solutions, in the 
form of more elaborate call and save sequences are also outlined in BD. 7. 03 


although they are perhaps not quite so easy to understand. 


Suffice to say that all these special sequences are supposed to be auto- 
matically generated by the Multics PL/I compiler and by at least one of the 
macro assemblers provided in the Multics public library. If you are writing 
your own target-code producing assembler or compiler and if you want it to 
be capable of generating E@ procedures, you will find it essential to gain a 
grasp of all the details in BD. 7.03. Hopefully, this chapter has prepared you 
for the challenge. | | 


of 


